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User-Defined Errors for RSVP 
Status of This Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 

Official Protocol Standards" (STD 1) for the standardization state 

and status of this protocol. Distribution of this memo is unlimited. 
Abstract 


The Resource ReserVation Protocol (RSVP) defines an ERROR_SPEC object 
for communicating errors. That object has a defined format that 
permits the definition of 256 error codes. As RSVP has been 
developed and extended, the convention has been to be conservative in 
defining new error codes. Further, no provision for user-defined 
errors exists in RSVP. 


This document defines a USER_ERROR_SPEC to be used in addition to the 
ERROR_SPEC to carry additional user information related to errors. 


1. Introduction 


The Resource ReserVation Protocol (RSVP) [RFC2205] defines an 
ERROR_SPEC object for communicating errors. That object has a 
defined format that permits the definition of 256 error codes. As 
RSVP has been developed and extended, the convention has been to be 
conservative in communicating errors. Further, no provision for user 
defined errors exists in RSVP. 


When developing extensions to RSVP, it is often useful for those 
implementing to define error messages to aid both in the initial 
debugging and in testing against older versions or other 
implementations. 


This document defines a new RSVP object to permit user-defined errors 
to be communicated. This will enable organizations to define errors 
that they can use for internal development. These error values could 
also be shared with the community at large to aid in promoting 
interoperability between diverse implementations. 
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RSVP PathErr and ResvErr messages require the presence of an 
ERROR_SPEC object ([RFC2205]). [RFC3473] defines the Notify message 
that also requires the presence of an ERROR_SPEC object. In order to 
not change the mandatory contents of these messages, this document 
defines a new error code value that indicates that the new object is 
present and carries a user-defined error code. 


Note that the ResvConf message defined in [RFC2205] also carries an 
ERROR_SPEC object. But this usage of the object does not carry 
meaningful Error Codes or Error Values and so the extensions defined 
in this document are not applicable to that message. 


1.1. Conventions 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 
2. User-Defined Error 
A new Error Code is defined for use in an ERROR_SPEC object. 


Error Code = 33: User Error Spec 


This error code is used to signal the presence of a 
USER_ERROR_SPEC. One Error Value is defined as follows. 


Error Value 0 = Further details in User Error Spec 


Further error values may be defined in future specifications. 


When sending this error code, a USER_ERROR_SPEC object MUST be 
included in the PathErr, ResvErr, or Notify message. 


3. USER_ERROR_SPEC Class 
A new RSVP object class called USER_ERROR_SPEC is defined. To 
support backwards compatibility, its class number is in the range 
192-247. As defined in [RFC2205], implementations that do not 


understand such an object will forward it unmodified. 


USER_ERROR_SPEC object: Class = 194, C-Type = 1 


Swallow & Farrel Standards Track [Page 2] 


RFC 5284 User-Defined Errors for RSVP August 2008 


0 pi 2 3 

O a E E e E e 950 T E S E E S 7 8-900 1.23. 4S 6. TB 9 
+--------------- +--------------- +--------------- +--------------- + 
| Enterprise Number | 
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Error Description 


4+--------------- 4+--------------- 4+--------------- 4+--------------- + 


User-Defined Subobjects Š 
+--------------- 4+--------------- +--------------- +--------------- + 
Enterprise Number 


A unique identifier of an organization encoded as a 32-bit 
integer. Enterprise Numbers (sometimes known as Private 
Enterprise Numbers) are assigned by IANA and managed on a first 
come first served basis through the IANA registry named 
"Enterprise Numbers" [RFC2578]. 


Sub Org 


A unique identifier of an organization encoded as an 8-bit 
integer. An organization MAY use this field to create 
independent Error Value spaces. This is intended to facilitate 
teams that are doing parallel development. If independent 
spaces are not required, this field SHOULD be set to zero. 


Err Desc Len 
The length of the error description in the Error Description 
field in bytes excluding any padding. Zero is a valid length 
if no error description is supplied. 

User Error Value 
A 16-bit integer. The meaning is specified by the 


(sub-)organization indicated by the Enterprise Number and Sub 
Org fields. 
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Error Description 


A string of characters padded with nulls (0x00) to a multiple 
of 4 bytes. According to the guidance in [RFC2277], this 
string MUST use UTF-8/Net-Unicode encoding [RFC5198]. 
Furthermore, it is RECOMMENDED that implementations limit the 
strings that they generate to single-line printable US-ASCII 
[ASCII] whenever feasible to improve the likelihood of easy use 
by the recipient. 


If the Err Desc Len is zero, then no bytes are supplied. 


Note that the content of this field is implementation-specific. 
It is typically printable, but might not be shown to all users 
in all implementations (because of character set choice). 
Therefore, the content of the field SHOULD be limited to 
supplementary information and SHOULD NOT contain information 
critical to operating the network. Critical information is 
present in the User Error Value field. 


User-Defined Subobjects 


User-defined subobjects MAY be included. The generic format of 
subobjects is specified in Section 3.1. The semantics of a 
subobject is indicated by the Type field, but the semantics, 
format, and contents of the Value field are specified by the 
(sub-)organization indicated by the Enterprise Number and Sub 
Org fields of this object. 


3.1. Subobjects 


Each subobject is encoded as a TLV in the following format: 


0 1 

OL. 2 349) 6 Tg GQ 12 3 AS 
toto tatatrtotatatrtotatataotita tates A + 
| Type | Length | (Subobject contents) 
a A a a L a a a + 
Type 


An 8-bit number assigned by the (sub-)organization indicated by 
the Enterprise Number and Sub Org fields of the USER_ERROR_SPEC 
object. 
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4. 


4 


Length 


The Length contains the total length of the subobject in bytes, 
including the Type and Length fields. The Length MUST be at 
least 4, and MUST be a multiple of 4. 


Procedures for Using the User Error Spec 
1. Procedures for Sending the User Error Spec 


A USER_ERROR_SPEC object MAY be included in any PathErr, ResvErr, or 
Notify message for any defined error code. The Enterprise Number 
MUST be a valid value assigned by IANA from the "Enterprise Numbers" 
registry. 


As specified in [RFC2205] and [RFC3473], an ERROR_SPEC object with a 
valid error code MUST be included in all PathErr, ResvErr, and Notify 
messages. This rule is not changed by these procedures even when a 
USER_ERROR_SPEC object is included. If no other error code applies, 
the Error Code in the ERROR_SPEC object MUST be set to "User Error 
Spec" as defined in Section 2 of this document. When the Error Code 
in the ERROR_SPEC object is set to "User Error Spec", the Error Value 
sub-code SHOULD be set to "Further details in User Error Spec" as 
defined in Section 2, but further Error Value sub-codes may be 
defined in future specifications. 


-2. Procedures for Receiving the User Error Spec 


It is RECOMMENDED that implementations that receive a PathErr, 
ResvErr, or Notify message carrying a USER_ERROR_SPEC object log (at 
a minimum) the Enterprise Number, Sub-organization, User Error Value, 
and Error Description. Note that the character set used for the 
Error Description may mean that it might not be suitable for display 
of logging in all systems. Implementations capable of interpreting 
the contents of the USER_ERROR_SPEC object SHOULD take further action 
based on the reported error. 


Implementations that are not UTF-8 capable and that receive a 
USER_ERROR_SPEC object SHOULD handle the Error Description according 
to the procedures set out in [RFC5137]. 


If a message is received containing an ERROR_SPEC object using the 
"User Error Spec" error code, but not containing a USER_ERROR_SPEC 
object, the message MUST be treated as malformed and handled 
according to [RFC2205]. 
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Implementations SHOULD ignore repeated occurrences of USER_ERROR_SPEC 
objects, and SHOULD forward them unchanged on any messages that they 
forward. This provides for forward compatibility. 
Implementations receiving a USER_ERROR_SPEC object on some message 
other than a PathErr, ResvErr, or Notify message MUST treat the error 
as a malformed message and process according to [RFC2205]. 

5. IANA Considerations 

5.1. RSVP Error Codes 


This document makes the following assignments from the RSVP Error 
Codes and Globally-Defined Error Value Sub-Codes registry: 


Error Code Meaning 
33 User Error Spec 


One Error Value sub-code is defined for use with this Error Code as 
follows: 


0 = Further details in User Error Spec 
5.2. RSVP Objects 


This document makes the following assignments from the RSVP Class 
Names, Class Numbers, and Class Types registry: 


Number Space Value Name 

Class Numbers 194 USER_ERROR_SPEC 

Class Type 1 User-Defined Error 
6. Security Considerations 


This document makes no changes to the basic message exchanges of 
[RFC2205] and [RFC3473]. It will result in a small increase in the 
number of error messages sent in cases where messages were previously 
Silently dropped due to the lack of an appropriate error code. 


The mechanisms defined in this document may be used by 


implementations to report additional error conditions and information 
arising from security issues and attacks on the RSVP network. 
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Note that the use of a character string that will be displayed or 
logged opens the potential for certain security attacks through the 
use of overruns or embedded control characters. Implementations 
SHOULD take precautions against overruns, and (especially where the 
full character set of [RFC5198] is not supported, SHOULD use the 
procedures set out in [RFC5137] to handle unexpected or unknown 
control characters. 
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